1. Field of the Invention
The present invention relates generally to resource-constrained devices such as smart cards, and more particularly to implementing servlet-based applications on resource-constrained devices.
2. Description of Related Art
Java Card™ technology enables programs written in the Java™ programming language and utilizing applets to be run on smart cards and other small, resource-constrained devices. (Java Card™ and Java™ are trademarks of Sun Microsystems, Inc. of Santa Clara, Calif.) Developers can build and test programs using standard software development tools and environments, then convert the programs into a form that can be installed onto a Java Card™ technology-enabled device. Java Card™ implementations support persistence of applet data across sessions where a session extends from insertion of the resource-constrained device into a card acceptance device (CAD) until removal of the resource-constrained device from the CAD.
Herein, the applet data is for applet applications, i.e., applications servicing requests over the ISO7816 APDU protocol. Applet applications include at least one applet.
While persistent memory is typically implemented with EEPROM (Electrical Erasable Programmable Read-Only Memory) and volatile/non-persistent memory is implemented with RAM (Random Access Memory), transient (that is non-persistent) objects may still be allocated in EEPROM when there is shortage of RAM memory. Typically, the amount of RAM, even on a high-end resource-constrained device, is small, e.g., 16 to 32 Kbytes.
Java Card™ implementations also support isolation of application execution contexts. Isolation means that a Java Card™ application cannot access data or code of an application in another context unless the other application explicitly provides an interface for access. Context isolation is enforced by Java Card™ firewalls. Applications can provide interfaces for other applications to access in the form of Shareable Interface Objects, which allow secure access across the application firewalls.
Application software for the Java Card™ platform was limited to implementing the Java Card™ applet application model. Typically, the Java™ Servlet-based application model, used on server machines, has not been implemented directly on resource-constrained device, such as smart cards, because as explained more completely below, resource-constrained devices do not include the resources found on server machines.
A servlet is a Java™ technology-based Web component managed by a container. Servlets are Java™ classes that are run by a Java™ technology-enabled Web server. A servlet container contains and manages servlets through their lifecycle. Servlets interact with Web clients via a request/response paradigm implemented by the servlet container. While not limited to it, a servlet container typically supports HTTP and HTTPS (HTTP over SSL or TLS) as a protocol for requests and responses. A servlet container may provide additional services to the applications being run by the servlet container.
Web applications are collections of servlets and other components and resources bundled along with a deployment descriptor to be deployed into a servlet container. The application deployment descriptor conveys the elements and configuration information of an application between the different actors during the application lifecycle, namely: application developers, application assemblers, and deployers or in the context of Java Card™ technology, smart-card issuers. To any Web application corresponds a context named a servlet context. A servlet context defines a servlet's view of the Web application within which the servlet is running.
The Hypertext Transfer Protocol (HTTP) is by design a stateless protocol. To build effective Web applications, it is imperative that requests from a particular client be associated with each other in what is called a session. Session tracking can be performed in a servlet-based application via instances of interface HttpSession.
Unfortunately, a smart card or other resource-constrained device does not include a disk drive, or large amounts of random access memory. Consequently, the servlet model that depends on secondary storage on disk drives and large amounts of memory on a server cannot be implemented directly in a smart card.
Servlet-based applications were originally intended to run on server machines, which are intended to be always on and which benefit from reliability, availability, and serviceability features so that downtime is avoided or limited. Unlike these server machines, when a new CAD session starts—that is the resource-constrained device has been inserted in a CAD—the platform is reset and the volatile memory is cleared. Thus, the content of the volatile memory is lost across CAD sessions. Only the persistent memory content is retained across CAD sessions.
The servlet model, which was originally designed for server-side applications, does not account for an environment where the system can be brought down at any time. Re-initializing the servlet-based applications upon each platform reset would induce a performance penalty, which is not compatible with smart card use. On the other hand, indiscriminately persisting all objects of a servlet-based application is not desirable since such persistence may imply additional cleanup to resume from a clean state. Moreover, storing session data in persistent memory may have a performance impact during application operations depending on the frequency of updates. Unfortunately, these factors inhibit the utilization of the servlet model to implement web-based applications on a resource-constrained device.